Private payment and purchasing system

ABSTRACT

A system allows for conducting the financial and commercial (buying, selling, donating, gifting and paying) transactions that leverage communication devices to avoid the disclosure of a user&#39;s payment information. The payee (seller, seller&#39;s agent, receiver of funds, etc.) provides information or a token to the payer (buyer, buyer&#39;s agent, or any other provider of funds) who then directs funds to that token. In other words, rather than the payer providing information that is used by the payee to “pull” funds from the payer, the system allows a payee to provide information to which a payer “pushes” a payment. Since the payment is “pushed” by a customer, and often, but not always, using some type of a communication and/or computing device, the point-of-sale (POS) terminal has essentially been transferred from the merchant to the customer.

This application claims priority to U.S. Provisional Patent Application61/331,881, entitled “Private Payment and Purchasing System,” filed May6, 2010, which is incorporated herein by reference in its entirety forall that it teaches and for all purposes.

BACKGROUND

In traditional non-cash transactions, a buyer is required to provide tothe seller some payment information with which the seller or payee(receiver of funds) “pulls” funds from the payer's account. Such anaccount may be held by a financial institution like a bank or creditunion or it could be held by a card company and in some cases by thirdparties like Paypal.

For example, in a card-present transaction, the card is handed to acashier who then electronically or manually accesses the cardinformation (either from the magnetic strip or off the face of the card)and uses it to pull funds from the payer's account. In acard-not-present transaction, such as on a website or on a call with asales associate of a merchant, the card information is provided to theseller or seller's agent and then this card information is used to pullfunds from the payer's account. Often, in addition to paymentinformation, additional information such as billing address, shippingaddress and phone numbers are also required to complete the transaction.The cards used in both card-present and card-not-present transactions,may be credit cards, debit cards (both PIN and signature) as well asgift cards (both open loop and closed loop).

In a check transaction, a check with the routing number, account numberand funds amount is provided to a seller or seller's agent or payee andthe information on the check is used to pull the funds. Severalalternative payment schemes have emerged where the payer's informationis kept hidden from the seller, seller's agent or receiver of funds(payee). In such payment schemes a trusted third party still acts as theescrow and holds the relevant information. This party may still “pull”the funds from a payer's bank account or credit card as in the case ofPAYPAL or directly offer credit as in the case of BillMeLater. In thesecases, nevertheless, the Point-Of-Sale (POS) resides with the merchant.Recently gift cards have emerged as a mechanism for transferring fundswithout disclosing payer's information. However, the gift card numberand associated information itself is often adequate to access the fundsstored in the card. The same is true for mobile devices with storedfunds using technologies like Near Field Communications (NFC).

SUMMARY

It is with respect to the above issues and other problems that theembodiments presented herein were contemplated. Embodiments described inthe present application provide systems and method for conducting afinancial transaction without a payer providing account information to apayee. Rather, a payee provides the payer a “token.” The token canidentify the payee and a product or service associated with thetransaction. The payer provides the token to a private payment systemwhich pays the payee using information in the token. After receivingpayment or an approval for payment, the payee can provide the product orservice.

The embodiments of the methods and systems for conducting the financialand commercial (buying, selling, donating, gifting and paying)transactions leverage communication devices to avoid the disclosure of auser's payment information. In embodiments, the payee (seller, seller'sagent, receiver of funds, etc.) provides information or a token to thepayer (buyer, buyer's agent, or any other provider of funds) who thendirects funds to that token. In other words, rather than the payerproviding information that is used by the payee to “pull” funds, theembodiments allow a payee to provide information to which a payer“pushes” a payment.

An example of a point-of-sale (POS) terminal is the credit card terminalthat accepts a swipe of the magnetic strip on the credit card or thenumber printed on the credit card. The POS terminal accepts accountinformation that can be used by the merchant to pull funds. In thepresent embodiments, a user's cell phone or another device is used toaccept information about the merchant, i.e., the customer receives atoken. The token is used by the customer to push funds. Since thepayment is “pushed” by a customer, and often, but not always, using sometype of a communication and/or computing device, the POS terminal hasessentially been transferred from the merchant to the customer.

Payee tokens can have different forms. The token can uniquely identifythe payee and may also identify a product or service or any other reasonfor the payment. One example of a payee token (or information that maybe included in the token) is a universal payment identification code(UPIC). A UPIC is a unique bank account identifier that has beenestablished by financial institutions in order to allow merchants andother organizations to receive electronic payments without disclosingtheir account information. UPIC was developed by the Electronic PaymentsNetwork (EPN).

Another example of a token, albeit significantly less secure for thepayee, is the payee's account number and routing number at a financialinstitution, for example, a bank or credit union account number androuting information. Another example might be a unique name or handle,such as, a mobile device number or a combination of a merchantidentifier (name, unique number, etc.). Another example might include ahandle or name that is pair-wise unique (i.e., the handle is uniquebetween a pair of individuals—e.g., “mom,” “dad,” “Dave,” or “JT”).

A merchant can include the token in an advertisement, announcement,catalog entry, webpage, receipt, invoice, bill, or any other statementabout a product or service offered. The token might consist of or bederived from a merchant identifier and a product identifier (stockkeeping unit (SKU) number). A purchaser or buyer of that merchant'sproduct or service may then “push” a payment to that token using aPrivate Payment System (PPS) described below. The merchant, uponreceiving notification of a payment received or payment approval, candeliver the product or service to the buyer either directly or throughan agent. The merchant advertisement or statement may be on TV, on abillboard, in a newspaper, on a radio broadcast, on an internet website,or sent to a mobile device.

The merchant code can be any tag that uniquely identifies a particularmerchant or a store. For example, the following table lists some wellknown merchants and some possible merchant codes or tokens:

Merchant name Possible codes Saks Fifth Avenue SAKS Neimann Marcus NM orNeimarc Starbucks STRBKS Ann Taylor ANTLR

In another example, a merchant could sign-up with PPS and can register amerchant code. A user who has signed up with PPS can use the merchantcode and a product number (for example, a product number in a catalog)to facilitate a purchase of the product. To purchase the product, thecustomer communicates the merchant code and product number to PPS. ThePPS confirms the product, its price, and fulfillment mechanism (i.e.where to send the product or service that was purchased—for example,send to user's email, home address, or work address). Then, the PPSconfirms the cuctomer's choice of payment (debit account or creditaccount—setup by the user). The PPS authenticates the user and completesthe transaction by sending a payment confirmation to the merchant alongwith a purchase order complete with shipping address and instructions.The user selected item is then delivered by the merchant to the user orthe service or product is provided, for example, seats at a stadium orauditorium are reserved, a customer pick-ups the product, etc. Uponprovided the product or service, the transaction is complete. In thistransaction, the user's payment information was never transmitted to themerchant. The merchant never having taken possession of the buyer'spayment information does not have to incur any liability surrounding itssecurity.

The PPS executes the “push” payment and purchasing described above. ThePPS can include a switch. A switch can be a component of the PPS thatcan interact with a user or merchant (a merchant may be an organizationor another person) to direct communications and data. The switchfunctions as an engine to effect push payments. A user wishing tofacilitate a payment or purchase communicates with the PPS through acommunications gateway using communications protocols that include butare not limited to short message service (SMS), instant messaging (IM)(e.g., Yahoo! Messenger, AOL Instant Messenger, etc.), unstructuredsupplementary service data (USSD), e-mail, interactive voice response(IVR), etc. In the message to the PPS, the user communicates the payee'stoken to the switch. The switch, through a token sub-system interactswith the merchant and/or independent parties, involved in processing themerchant's payments, associated with that token. The independent partiesmay include contracted entities or other entities that process paymentsfor the merchant) In particular, the token sub-system interacts withmerchant's product data store, which may be off-site or local to themerchant, to determine the product being purchased by the user. Theswitch, after authenticating the user and establishing availability offunds, generates a order and/or payment. A payment and order processingsub-system of the PPS sends an payment approval and/or an order,possibly along with notification of payment or approval of the paymentof funds to the merchant's bank or UPIC, to the merchant's orderprocessing system to complete fulfillment. The order also includesfulfillment instruction including where the product or service is to besent (physical address, email address, mobile device, etc.)

The payment and order processing sub-system can generate the paymenttransfer instructions and send the funds to the PPS funds sub-system orbank, which then transfers payments to the merchant or payee's bank orUPIC via automated clearing house (ACH) transmission or an electronicfunds transfer (EFT). A copy of the purchase order and a confirmation ofthe payment (including tracking information obtained from the merchant)is sent to the switch, where the switch can store a copy and send it tothe user.

The authentication of the user is carried out by the authenticationsub-system. The authentication sub-system can use a multi-factorauthentication. For example, the multiple factors may be: a) anauthorized phone number (mobile phone, home phone, office phone, etc.);b) a personal identification number (PIN) or password; c) the activity,which can trigger additional or different checks, for example, arestricted fulfillment, i.e., the product or service is restricted to alimited set of addresses (physical or electronic) that can be under thecontrol of the user, or a change of addresses. In other words, even ifa) and b) were compromised the benefit of the payment is restricted topre-set fulfillment addresses.

In another example of when addition authentication is sued, a user mayuse the PPS is used to transfer funds to another PPS user. If the useris trying to transfer funds to another user, then additional challengequestions can be posed by the authentication sub-system that must beanswered by the user before the transaction can be completed. Theauthentication sub-system may also determine the authenticity of thetransaction, based on other metrics, or may pose challenge questions.

The PPS may offer a user the ability to make either a debit payment or acredit payment. In case a debit payment is chosen, then a debitsub-system can verify the user's balance, sequester the requisite amountfor the payment, authorize the payment and notify the PPS of theauthorization. If the debit funds are inadequate, then the debitsub-system may notify the switch, which can then notify the user. Theuser may then choose to use credit through the credit sub-system orreplenish the debit account.

The credit sub-system can verify a user's credit limit to determinewhether the purchase amount can be supported. If the purchase amount canbe supported, then the switch is notified and the transaction iscompleted. If the purchase cannot be supported, the user is notified orthe credit limit is increased based on the user's credit worthiness.Credit worthiness may be determined by methods well known to thoseskilled in the art.

The fulfillment sub-system can control the delivery of product andservices. The fulfillment system may store or contain the user'spre-determined methods that are to be used for delivery products and/orservices. Thus, the data stored by the fulfillment system can includeelectronic and physical addresses where goods are to be shipped or thatthe user desires to use in-store pickup. When using in-store pickup, thefulfillment data may include security instructions that the personpicking up the good will need to provide identification and proof of thesale, e.g., a receipt. The pre-determined addresses can be changed butonly through additional electronic access, which is secured withadditional passwords, pins, and other security measures.

The users of the PPS can setup or establish their profile and relatedinformation. This information may be stored and maintained in the userprofile subsystem (UPS). The UPS may store a user's information, whichcan include one or more of, but is not limited to, name, address,electronic address, phone number, transaction phone number, date ofbirth, social security number, etc. A user can also setup a network offriends and family by importing contact information from an existingcontact system (like MS Outlook™), Facebook, their handset, or othersystems. The entry of the information may be automatic or manual. A usermay attach a special name or tag with some (or all) of the contacts. Forexample, the user may use the tags “Dad,” “Mom,” “Uncle Dave,” “GrandmaSusan,” etc. These special names, tags, or handles can be stored astokens described earlier for facilitating payments and/or giftingbetween PPS users.

In addition, each user can setup funds transfer vehicles. Such vehiclescan include one or more of, but are not limited to, bank account(s)(with account number, routing number, and/or other identifiers),re-loadable gift cards, merchant cards (e.g. Starbucks cards), payrollcards, debit cards, etc. The vehicles may provide the users with theability to transfer funds into their PPS accounts from their bankaccounts, gift cards etc. Further, the vehicles also afford the user theability to transfer funds into another members account in the PPS. Thetransfer vehicles can also provide individuals in a user's network totransfer funds into the user's account(s) or cards. Finally, transfervehicles may allow a user to setup one or more anonymous handles, whichcan be used for transactions with “strangers” to whom a user may notwish to divulge phone numbers, names, or payment information. Such acapability is useful when individuals are making purchases of goods andservices advertised in newspapers, electronic boards (like Craigslist),and other media. The user may also establish a default currency in whichtransactions are to be made. For example, customers in the United Stateswill have a default currency in U.S. dollars.

In addition to transactions with merchants, the PPS can also be used tofacilitate transactions between individuals. Individuals might bemembers of a professional, family, or social network, and thetransactions envisioned might include, but are not limited to, payments,gifting, and establishing tabs (funds owed between individuals).

The term “network” as used herein refers to a group of individuals, asocial network, and/or a system used by one or more users tocommunicate. The network can consist of one or more servers,communication endpoints, computer systems, etc. that allowcommunications, whether voice or data, between two or more users. Anetwork can be any network or communication system as described inconjunction with FIGS. 6 and 7. Generally, a network can be a local areanetwork (LAN), a wide area network (WAN), a wireless LAN, a wirelessWAN, the Internet, etc. that receives and transmits messages or databetween devices. A network may communicate in any format or protocolknown in the art, such as, transmission control protocol/internetprotocol (TCP/IP), 802.11g, 802.11n, Bluetooth, or other formats orprotocols.

The term “database” or “data model” as used herein refers to any system,hardware, software, memory, storage device, firmware, component, etc.,that stores data. The data model can be any type of database or storageframework described in conjunction with FIGS. 6 and 7, which is storedon any type of non-transitory, tangible computer readable medium. Thedata model can include one or more data structures, which may compriseone or more sections that store an item of data. A section may include,depending on the type of data structure, an attribute of an object, adata field, or other types of sections included in one or more types ofdata structures. The data model can represent any type of database, forexample, relational databases, flat file databases, object-orienteddatabases, or other types of databases. Further, the data structures canbe stored in memory or memory structures that may be used in eitherrun-time applications or in initializing a communication.

The phrases “at least one”, “one or more”, and “and/or” are open-endedexpressions that are both conjunctive and disjunctive in operation. Forexample, each of the expressions “at least one of A, B and C”, “at leastone of A, B, or C”, “one or more of A, B, and C”, “one or more of A, B,or C” and “A, B, and/or C” means A alone, B alone, C alone, A and Btogether, A and C together, B and C together, or A, B and C together.

The term “in communication with” as used herein refers to any coupling,connection, or interaction using electrical signals to exchangeinformation or data, using any system, hardware, software, protocol, orformat.

The term “a” or “an” entity refers to one or more of that entity. Assuch, the terms “a” (or “an”), “one or more” and “at least one” can beused interchangeably herein. It is also to be noted that the terms“comprising”, “including”, and “having” can be used interchangeably.

The term “automatic” and variations thereof, as used herein, refers toany process or operation done without material human input when theprocess or operation is performed. However, a process or operation canbe automatic, even though performance of the process or operation usesmaterial or immaterial human input, if the input is received beforeperformance of the process or operation. Human input is deemed to bematerial if such input influences how the process or operation will beperformed. Human input that consents to the performance of the processor operation is not deemed to be “material”.

The term “computer-readable medium” or “computer program product” asused herein refers to any tangible storage that participates inproviding instructions to a processor for execution. Such a medium maytake many forms, including but not limited to, non-volatile media,volatile media, and transmission media. Non-volatile media includes, forexample, NVRAM, or magnetic or optical disks. Volatile media includesdynamic memory, such as main memory. Common forms of computer-readablemedia include, for example, a floppy disk, a flexible disk, hard disk,magnetic tape, or any other magnetic medium, magneto-optical medium, aCD-ROM, any other optical medium, punch cards, paper tape, any otherphysical medium with patterns of holes, a RAM, a PROM, and EPROM, aFLASH-EPROM, a solid state medium like a memory card, any other memorychip or cartridge, or any other medium from which a computer can read.When the computer-readable media is configured as a database, it is tobe understood that the database may be any type of database, such asrelational, hierarchical, object-oriented, and/or the like. Accordingly,the invention is considered to include a tangible storage medium andprior art-recognized equivalents and successor media, in which thesoftware implementations of the present invention are stored.

The terms “determine”, “calculate”, and “compute,” and variationsthereof, as used herein, are used interchangeably and include any typeof methodology, process, mathematical operation or technique.

The term “module” as used herein refers to any known or later developedhardware, software, firmware, artificial intelligence, fuzzy logic, orcombination of hardware and software that is capable of performing thefunctionality associated with that element. Also, while the invention isdescribed in terms of exemplary embodiments, it should be appreciatedthat individual aspects of the invention can be separately claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure is described in conjunction with the appendedfigures:

FIG. 1 is a block diagram of an embodiment of a system for conducting apush payment;

FIG. 2 is a block diagram of an embodiment of a PPS operable to conducta push payment;

FIGS. 3A through 3C are block diagrams of embodiments of data structuresoperable to store token information;

FIG. 3D is a block diagram of an embodiment of a data structure operableto store user profile information;

FIGS. 3E and 3F are block diagrams of embodiments of data structuresoperable to store tab information;

FIGS. 4A through 4D are flow diagrams of an embodiment of a process forconducting a push payment;

FIGS. 5A through 5C are flow diagrams of an embodiment of a process forcreating and settling tabs;

FIG. 6 is a block diagram of an embodiment of a computing environmentoperable to execute the embodiments described herein;

FIG. 7 is a block diagram of an embodiment of a computer or computingsystem environment operable to execute as the one or more devicesdescribed herein.

In the appended figures, similar components and/or features may have thesame reference label. Further, various components of the same type maybe distinguished by following the reference label by a letter thatdistinguishes among the similar components. If only the first referencelabel is used in the specification, the description is applicable to anyone of the similar components having the same first reference labelirrespective of the second reference label.

DETAILED DESCRIPTION

The ensuing description provides embodiments only, and is not intendedto limit the scope, applicability, or configuration of the claims.Rather, the ensuing description will provide those skilled in the artwith an enabling description for implementing the embodiments. It beingunderstood that various changes may be made in the function andarrangement of elements without departing from the spirit and scope ofthe appended claims.

A system 100 can affect payments to and/or from users and/or merchantsto purchase services and goods. The system 100 can include one or morecomponents, which may be hardware and/or software that can be includedin one or more computer systems, as described with FIGS. 6 and 7. Thecomponents may include one or more of, but is not limited to, one ormore users 102, one or more networks 110, a private payment system 108,one or more merchants 112, at least one gateway 106, and/or one or moredatabases 114. Each of these components will be described hereinafter.

A user 102 can be any computer system or device used by a person orentity purchasing services or goods. Thus, the user may be representedby a laptop or desktop computer 102 a, a user mobile device 102 b, orone or more other types of user devices. There may be more or fewerusers and/or user devices than those shown in FIG. 1, as represented byellipses 104. A user can be any consumer, whether a person ororganization, that purchases services or goods. The user computersystems can communicate with a network 110 to send or receive data orother communications to/from a gateway 106.

A network 110 can be any network used to communicate information betweentwo or more computer systems. In embodiments, the network 110 may alsorepresent phone systems or other means of communicating information froma user to a private payment system 108. Thus, the network 110 canrepresent systems or networks for completing phone orders or other typesof communication systems. A network 110 can communicate in any protocolor format. The network 110 can be an intranet, the Internet, the WorldWide Web, etc. In other embodiments, the network 110 may be a publicswitched telephone network (PSTN) or other type of phone system.

A gateway 106 can be a system that manages communications for a privatepayment system 108. The gateway 106 can be any set of hardware and/orsoftware operable to facilitate communications. The gateway 106 may beoperable to form communications into one or more user-specific protocolsto be sent to the user 102. Thus, if the user is operating a mobiledevice, the gateway 106 may be operable to put the private paymentsystem communications into a format that may be received by the mobiledevice 102 b.

A merchant or merchant system 112 can be any type of hardware and/orsoftware that is operable to process orders for or requests forinformation about goods or services and/or to receive payment for goodsor services. It should be noted that a merchant, as used herein, caninclude organizations, for example, big-box retails (e.g., Best Buy,Sears, etc.), online retailers e.g., (Amazon, Zappos, etc.), otherretailers, distributors, manufacturers, etc. and can includeindividuals. If the merchant is an individual, the transactions with thePPS 108 are essentially person-to-person. The merchant system 112 caninclude ordering systems, financial institution systems, and/or othersystems that may receive payment and/or process orders to be sent to auser 102.

A merchant 112 can create a token for the merchant's products orservices using the PPS 108. The token may then be used to facilitate thebuying of the merchant's products or services. The token is the“property” of the PPS 108, but the merchant 112 effectively “rents” thetoken for their use. The token, if acquired and employed, by a consumer,provides a gateway into the merchant's product(s) or service(s). Thetoken contains the merchant's purchasing information.

It should be noted that merchant 112 can be broadly interpreted to meanindividuals and not just organizations. Therefore, individuals utilizingFacebook, YouTube, or other social networking sites can employ atransactional capability by acquiring a token from the PPS 108 and usingthe token to communicate the purchasing details for a product orservice. The visual appearance of the token may include visual cues asto the identity of the merchant, e.g., a company logo, a brand name,other trademark, and the token can indicate that the PPS 108 isproviding the transactional capability.

The database 114 can be any database or storage system as described inconjunction with FIGS. 6 and 7. The database 114 can store informationas described in conjunction with FIGS. 3A through 3F. The database 114may store this information in one of several different formats or bydifferent methods, for example, a relational database, a flat filedatabase, an object oriented database, etc. The database 114 allows theprivate payment system 108 to both store and retrieve data forprocessing payments to and from users, and/or between users andmerchants. In embodiments, the database 114 may be a part of the privatepayment system 108 or maybe a separate storage system that is incommunication with the private payment system 108 but does not storeinformation locally.

The private payment system 108 can be any hardware and/or softwareoperable to process payments to from users 102 and/or from users 102 tomerchants 112. An embodiment of the private payment system 108 isdescribed in conjunction with FIG. 2. The private payment system 108 canreceive tokens from a user 102 that allows the private payment system108 to direct payment to a merchant 112. Further, the private paymentsystem 108 can process orders for the user 102 from the merchant 112.Thus, the private payment system 108 can facilitate the purchasing ofservices and goods between users 102 and merchants 112, or between twoor more users 102, without providing user financial data to the payee,whether another user 102 or a merchant 112.

An embodiment of a private payment system (PPS) 108 is described inconjunction with FIG. 2. The private payment system 108 can be acomputer system as described in conjunction with FIGS. 6 and 7. Theprivate payment system 108 may include hardware and/or software operableto conduct the functions described herein. In embodiments, the privatepayment system 108 can include one or more components, modules, orsystems which may be hardware and/or software that execute differentfunctions. In embodiments, the private payment system 108 can includeone or more of, but is not limited to, a user system 204, a privateprocessing switch 202, a merchant system 218, a PPS funds subsystem 230,a user authentication subsystem 226, and/or a tab subsystem 228.

The private processing switch 202, in embodiments, can be hardwareand/or software. However, the private processing switch 202 will beexplained as being a software module hereinafter, but the embodimentsshall not be so limited. The private processing switch 202 is able toreceive communications from the user 102, the merchant 112, thefinancial institution(s) 236, or other external entities to the privatepayment system 108. The private processing switch 202 can reroute thecommunication(s) to one or more subsystems within the private paymentsystem 108. As such, the private processing switch 202 functions as anengine to provide functionality to the private payment system 108 andcomplete transactions conducted by the private payment system 108. Inembodiments, the private processing switch 202 receives communicationsfrom a user 102 and sends the user communications to a user subsystem204.

The user subsystem 204 is operable to conduct one or more functions inresponse to user interactions. Thus, the user subsystem 204 can includeone or more subsystems, which can complete the one or more functions forthe user. The one or more subsystems can include one of more of, but arenot limited to, a fulfillment subsystem 206, a reward subsystem 208, acredit subsystem 210, a debit subsystem 212, and/or a currency subsystem214. Each of these one or more subsystems will be described in moredetail hereinafter.

A fulfillment subsystem 206 may be operable to complete the payment oftabs or other orders or financial transactions for the user. As such,the fulfillment subsystem 206 can interact with one or more othersubsystems to receive money that may then be forwarded to the privateprocessing switch 202 to send to a merchant system 112. The fulfillmentsubsystem 206 can take in one or more tokens, determine a price orreceive a price for a service or good, and then arrange for the paymentof the service or good. The fulfillment subsystem 206, in furtherembodiments, can also control the delivery of a product or service.Thus, the fulfillment subsystem 206 can receive information from a user102 about how a product or service should be delivered to the user. Inembodiments, the user 102 can determine, for all products or servicesordered through the private payment system 108, how delivery should becompleted and pre-set the delivery methods. For example, the deliveryaddress for a product may be provided or the default device to downloadsoftware may be provided, or other information to complete thefulfillment of the order may be provided and stored. Thus, thefulfillment subsystem 206 can save any predetermined methods or data,such as, specific electronic or physical addresses, to be used in thedelivery of a product or service. This information may be stored in thedatabase 114. In embodiments, the data can only be changed throughspecific passwords or additional security measures, such that, thisinformation can only be controlled by the user and is maintainedsecurely within the private payment system 108.

A rewards subsystem 208 can maintain rewards data for the user 102. Arewards subsystem 208 can function to offer purchase rewards similar toa customer appreciation or loyalty program, as offered through one ormore retailers. Thus, the rewards subsystem 208 provides the same typeof user benefit as those systems while the user employs the privatepayment system 108. In other embodiments, the rewards system 208 canstore the rewards offered from the merchants that are provided to theprivate payment system 108 after the purchase of a good or service.Thus, the reward subsystem 208 can provide a clearing house for rewardsto the user while giving the user a single interface to review rewardsfrom two or more merchants.

The credit subsystem 210 can be operable to pay for services or goodsrequested by the user 102 using a credit payment. In an embodiment, thecredit payment may be from a user's credit card or other accountprovided to the credit subsystem 210 by the user 102. In otherembodiments, the credit subsystem 210 functions as a credit account.Thus, the credit subsystem 210 can maintain a credit account for theuser 102 with a credit limit. The credit subsystem 210 can verifywhether the purchase price is lower than the user's credit limit. If theprice is below the user's credit limit, the credit subsystem 210 canapprove the purchase and inform the private processing switch 202. Theprivate processing switch 202 can then direct other subsystems tocomplete the order. If the user's credit limit is not above the purchaseprice, the credit subsystem 210 can either disapprove of the purchase (adisapproval message is then sent to the private processing switch 202)or can increase or change the user's credit limit to complete the order.Thus, the credit subsystem 210 provides a method for payment of goods orservices through the private payment system 108 that allows the user touse credit rather than debit or other forms of payment.

In other embodiments, the user may pay for the good or service using adebit subsystem 212. The debit subsystem 212 can maintain an accountholding a payment or balance for the user 102. The debit subsystem 212can verify the purchase price of any good or service against the user'sbalance. If the purchase prices is less than the user's balance, thedebit subsystem 212 can sequester the purchase price amount and informthe private processing switch 202 that the funds are available topurchase the good or service. The authorization may be sent to theprivate processing switch 202, such that, the private processing switch202 can direct other subsystems to complete the transaction. However, ifthe debit account has inadequate funds, the debit subsystem 212 cannotify the private processing switch 202, which may then notify the user102 that there are inadequate funds to use the debit subsystem 212. Theuser 102 may then direct funds to the private processing switch 202 toreplenish the debit account stored within the debit subsystem 212. Inother embodiments, the user 102 may choose a different payment system,such as, the credit subsystem 210.

The currency subsystem 214 affords the user 102 the ability to purchasegoods from foreign vendors or to use different types of currency inpurchasing goods or services. In embodiments, the currency subsystem 214can convert the currency being used by the user into some other form ofcurrency. Thus, the currency subsystem 214 can maintain current exchangerates or be able to retrieve current exchange rates for different typesof currency. The currency subsystem 214 can receive a purchase amount ina first currency and convert the purchase amount to a different currencyto be used with the other subsystems in the user system 204. Inembodiments, the private processing switch 202 may direct any orderthrough the currency subsystem 214 before sending that order on to thecredit subsystem 210 or debit subsystem 212. In other embodiments, thecredit subsystem 210 or debit subsystem 212 may contact the currencysubsystem 214 when a conversion is necessary. Further, the PPS 108 mayalso use a new and different currency. Thus, exchanges within the PPS108 are agnostic and all currencies entering the PPS 108 are convertedbefore transactions are completed.

A user profile subsystem 216 may be operable to create a profile of theuser. The user profile subsystem 216 can retrieve or receive informationabout the user. This information may include the users name, one or moreidentifiers (such as, a social security number), phone numbers,electronic addresses, or other information that is associated with theuser. This user information may be stored in the database 114 and usedeither in payment or in order fulfillment by the user system 204 or oneor more other systems in the private payment system 108.

The private processing switch 202 may also communicate with the merchantsystem 218 to conduct actions with the merchant 112. The merchant system218 is operable to communicate with a private payment system fundsubsystem 230 which may communicate with one or more financialinstitutions 236. Further, the merchant system 218 communicates with oneor more merchants 112. The merchant subsystem 218 is operable to conductactions that allow the merchant 112 to provide goods or services to auser 102 using the private payment system 108. A merchant system 218 caninclude one or more subsystems, which can include one or more of, butare not limited to, a token subsystem 220, a payment order subsystem222, and/or a promotion subsystem 224. Each of these differentsubsystems will be explained in turn hereinafter.

The token subsystem 220 is operable to receive a token from the privateprocessing switch 202. The token subsystem 220 is operable tocommunicate with the merchant 112 associated with the tag(s) orinformation in the token. Thus, the token subsystem 220 is operable toretrieve information from the database 114 associated with the token.From this information, the token subsystem 220 can identify the merchant112 to which the token is associated. The token subsystem 220 may thencommunicate with the merchant 112 to determine information about theproduct also identified in the token. Thus, the token subsystem 220 cancommunicate with a product data store associated with the merchant 112that may include one or more SKU numbers or other data identifying theproduct or service within the token. The token subsystem 220 may thenreceive information, such as the price of the product or service, tothen affect payment for the good or service. The token subsystem 220 cancommunicate the information received from the merchant 112 to theprivate processing switch 202 to then use in processing the order withuser system 204. In embodiments, the product data store associated withthe merchant may be stored by a third party or off-site from themerchant 112. Regardless, the token subsystem 220 can communicate with adata source either local with the merchant or operated by a third partyto retrieve information about the product or service associated with thetoken received at private processing switch 202.

Payment information received from the private processing switch 202, ascompiled by the user system 204, may be sent to a payment ordersubsystem 222. The payment order subsystem 222 can push the payment to aPPS fund subsystem 203. The payment information may be formatted into aprotocol or data packet, as required by the financial institution 236.For example, the PPS fund subsystem 230 can take the payment informationfrom the private processing switch 202 and create an ACH transfer forthe merchant 112. Thus, the PPS fund system 230 can push funds from theuser to the merchant's financial institution 236 without the merchantever receiving account information from the user. The methods forpayment by the PPS funds subsystem 203 can include sending ortransferring money to the merchant's bank or UPIC using ACH, EFT orother types of systems used for electronic or other payments. Thepayment order system 222 can receive a confirmation of the financialpayment from the PPS fund system 230 or directly from the financialinstitution 236. This payment information may be forwarded to theprivate processing switch 202 to send to the user 102.

Upon receiving confirmation of payment for the good or service, thepayment order system 222 can communicate with the merchant 112 tocomplete the order. In embodiments, the payment order system 222 cancreate a purchase order that is sent to the merchant 112. The paymentorder subsystem 222 can also wait and confirm delivery of the good orservice with the user 102 through the private processing switch 202.Thus, the payment order subsystem 222 can maintain open orders untilconfirmation of delivery of the service or good is received from theuser 102. In other embodiments, the payment order system 222 may alsosend the confirmation of payment to the merchant 112 as part of thecompletion of the order. Thus, the merchant 112 may be paid beforehaving to send goods or services and receive confirmation of thepayment. Thus, the merchant 112 need not receive account informationfrom the user 102 as the merchant 112 was paid before having to deliverthe services or goods to the user 102. The purchase order sent by thepayment order subsystem 222 can contain various information including,but not limited to, the address to deliver service or goods, theelectronic address to deliver a service or good, the fulfillmentprocedures as contained within the fulfillment subsystem 206, or otherinformation needed by the merchant 112 to complete the order.

A promotion subsystem 224 can store or inquire about promotions from themerchant 112. In embodiments, the promotion subsystem 224 can maintain alist of sales data or other information that may be used in theprocessing of the order with the merchant 112. In other embodiments, thepromotion subsystem 224 can receive any benefits for the user regardingthe order placed by the user 102. These benefits may include points,airline miles, cash back, or other rewards that may then be transferredto the user's specific rewards section in the rewards subsystem 208. Instill other embodiments, the merchant 112 may reward a customer usingthe PPS 108 currency described above. Thus, the customer gets “cashback” but in a currency used with the PPS 108, which may motivatefurther purchasing with the PPS 108.

A user authentication subsystem 226 can authenticate a user 102 whenconducting transactions with the user 102. The user authenticationsubsystem 226 can verify security data such as, usernames, passwords,personal identification number(s) (PIN), or other such data that may bestored in the user profile generated by the user profile subsystem 216and stored in the database 114. The authentication can be through anyknown method or security protocol known in the art. The userauthentication subsystem 226 may also have one or more different typesof authentication to use with each user 102 based on the actionsrequested by the user 102. For example, processing of a token may take afirst level of authentication, but a second level of authentication maybe used when the user 102 wants to change account information or accessother more highly protected information stored within the database 114.Thus, the user authentication subsystem 226 protects the user's datafrom unauthorized use.

A tab subsystem 228 is operable to store, retrieve, reconcile, orotherwise act on one or more tabs stored within the private paymentsystem 108. A tab, as the name indicates, can be an IOU or other type ofinformation that represents a debt owed from a first user 102 to asecond user, or to a merchant 112. The tabs may be created by the user102 or by someone that the user 102 owes money. A description of thetabs is provided in conjunction with FIGS. 3E and 3F. The tabs may bestored in the database 114 by the tab subsystem 228.

An example of a token 302 for conducting push payments is shown in FIGS.3A through 3C. The token 302 shown in FIG. 3A through 3C may include oneor more data structures. For example, the token 302 can include a payeeidentity data structure 304 and a product/service data structure 306shown separately in FIGS. 3B and 3C respectively. The data structures302 and 306 may include one or more portions that store information.Each portion may store one or more items of information. The token 302can include more or fewer fields than that shown in FIG. 3A, asrepresented by ellipses 308. Several tokens 302 may be stored orcommunicated by the private payment system 108. The one or more tokens302 may be stored in the database 114. Embodiments of information thatmay comprise the payee identity 304 are shown in FIG. 3B.

The payee identity 304 can include one or more of, but is not limitedto, a UPIC 310, a payment account number 312, a routing number 314,unique name 316, a phone number 318, and/or payer-wise name 320. Thepayee identity 304 can include more or fewer fields than those shown inFIG. 3B, as represented by ellipses 332. The UPIC 310, or universalpayment identification code, can be the UPIC identifier for the merchant112. This UPIC number may be stored as part of the token by the merchant112.

In other embodiments, the payee identity 304 can include the payeeaccount number for the merchants' financial institution account 236.Further, the payee account number 312 can be combined with the routingnumber 314 for the financial institution 236. The payee account number312 and routing number 314 provide enough information to completepayment for the merchant 112. A unique name 316 can be a name created bythe private payment system 108 or the merchant 112 that uniquelyidentifies the merchant 112 from other merchants. This unique name 316can be a globally unique identifier (GUID), an alpha numeric number, aspecialized name or abbreviation, or other type of identifier thatuniquely identifies the merchant 112. In other embodiments, the payeeidentity 304 can be the phone number 318 for the merchant 112. The phonenumber 318 can be used by the private payment system 108 to access otherinformation from the database 114 to effect payment and ordering ofgoods or services with the token 302.

The payee identity 304 can also include a merchant-created pair-wisename 320. The pair-wise name 320 can be an association that uniquelyidentifies the merchant 112. For example, the pair-wise name 320 can bea name of a type of business the merchant does that can that woulduniquely identify the merchant 112. For example, if the merchant 112 isa book store located in a certain area code, the pair-wise name 320could be an area code with the bookstore name, e.g., Borders 303. Thus,this pair-wise name 320 would identify that bookstore among all otherbookstores in that area code. In other embodiments, the user 102 maycreate the pair-wise name 320 and store that as part of the token in thedatabase 114. Thus, the information shown in the payee identity 304 canbe information stored in the database 114 and information communicatedwith the token 302. If one or more of the fields in the payee identity304 is received, other information may be retrieved from the database114 that may be associated with that token 302. The user 112 canidentify people using the pair-wise name 320, while some of the otherinformation may be received from a merchant 112 in a token 302 providedby the merchant 112. For example, the pair-wised name 320 can be adesignation by the user, such as, Aunt Jane. The pair-wise nature of thename is that this user's Aunt Jane can be identified by the associatedbetween the user and the name of his aunt.

One or more fields that may be included in the product/serviceinformation 306 are shown in FIG. 3C. FIG. 3C may include more or fewerfields than those shown, as represented by ellipses 334. In embodiments,the product/service information 306 may include one or more of, but isnot limited to, a stock keeping unit (SKU) number 322, a unique name ofthe product or service 324, a catalog number 326, price information 328,and/or fulfillment information 330. The information shown in FIG. 3C maybe stored in database 114 or provided within the token 302 used by themerchant 112 for a user 102. Thus, if one or more of the fields areidentified within the token 302, then other information may be retrievedfrom the database 114, although that information may be shown as part ofthe product or service portion 306 of the token 302.

A SKU 322 may be a unique identifier for the product or service within adatabase of goods or services stored with the merchant 112. The SKU 322can be a bar code or other visual information or may be a unique numberor alpha numeric identifier for the good or service. This SKUinformation may be provided to the merchant 112 to identify the productor service associated with the token 302. A unique name 324 may be aname used by the merchant 112, in identifying the good or service in acatalog for good or services provided by the merchant 112. A catalognumber 326 may be a number within a particular catalog used by themerchant 112. Thus, the catalog number 326 can include the identifierfrom which catalog the information comes from and also the product orservice number provided within the catalog.

A price 328 may be included with the token or may be retrieved eitherfrom the database 114 or from the merchant 112. The price 328 can be acurrency or a numeric value for the good or service. Currency may alsobe listed with the price 328 to provide the currency subsystem 214 withinformation about what currency should be used for payment of the goodor service. Fulfillment information 330 may include information providedby the merchant 112 to be used with the information stored by thefulfillment subsystem 206 to fulfill the order associated with the token302. This fulfillment information 330 can include payment information,address information, or other information useful for the private paymentsystem 108 to complete the order.

An embodiment of a user profile 336 is shown in FIG. 3D. The userprofile 336 may be created from information received by the user or frominformation obtained by the PPS 108. The user profile 336 may be storedin the database 114. The user profile 336 may include one or more of,but is not limited to, a name 338, an ID 340, contact information 342,PIN 344, fulfillment information 346, authentication information 348,challenge information 350, account information 352 and/or friend'sinformation 354. In embodiments, the user profile 336 may include moreor fewer fields then that shown in FIG. 3D, as represented by ellipses356. Each of these different types of information will be describedherein after.

A name 338 can include the actual name, username, or some type ofidentifier (ID) of the user 102 of the private payment system 108. Forexample, the name 338 may be a first name and last name. In otherembodiments, the name 338 can include the username, employed by theuser, to log into the private payment system 108. An ID 340 can includean ID unique to the user that may be used in electronic communicationsor may be used by the user to mask their name. The ID 340 can include asocial security number, a global unique identifier (GUID), or other ID,either automatically generated by the private payment system 108 orcreated manually by the user.

Contact information 342 can include the address, phone number, e-mailaddress, or other information for contacting the user. This contactinformation 342 may be entered by the user when creating a profile 336with the private payment system 108. In other embodiments, the contactinformation 342 may be procured automatically by the private paymentsystem 108 in interactions with the user 102. For example, the contactinformation 342 can include an e-mail address used to send informationto the private payment system 108, an electronic address used tocommunicate with the private payment system 108, or other types ofinformation that are automatically created and provided to the privatepayment system 108.

A personal identification number (PIN) 344 can be a user generated orautomatically generated number used by the user 102 for authenticationpurposes or other security measures. For example, when the user 102 logsinto the private payment system 108, with the user authenticationsubsystem 226, the user 102 may provide the name 338 and the PIN 344 toaccess the information stored in the user profile or to conducttransactions with the token.

Fulfillment information 346 may be the information used by thefulfillment subsystem 206 to determine how to fulfill a transaction withthe user 102. The fulfillment information 346 may be generated orpre-set by the user 102 and stored within the database 114 to be usedlater by the payment order subsystem 222 in conducting transactions. Thefulfillment information 346 can include what addresses to use forshipping addresses or which electronic addresses to use for sendingelectronic media, can include how to make payments to a merchant orother user, or can include other information used to conduct thetransactions described herein.

Authentication information 348 may be the one or more items ofinformation used by the user authentication subsystem 226 to determinethe identity of and authenticate the user 102. This authenticationinformation 348 can include one or more of, but is not limited to, apassword, a security question, or other information that may besupplement information already included in other sections of the userprofile 336. For example, that authentication information 328 caninclude a different username for the user 102, which is not included inthe name field 338. The authentication information 348 may be encryptedand stored within the user profile and accessed by the userauthentication subsystem 226 to verify the identity of the user 102.

The challenge information 350 can include one or more sets ofinformation that can be used by the user authentication subsystem 226for enhanced security measures. The challenge information 350 caninclude other information or security questions used by the userauthentication system 226 to insure the user identity before allowingcertain tasks. For example, if the user wishes to change the userprofile 336, the fulfillment subsystem information 346, the creditsubsystem and debit subsystem information, the challenge information 350may be accessed to determine or insure the user's identity.

Account information 352 can include the one or more credit or debitaccounts used by the credit subsystem 210 or the debit subsystem 212 forpayment. The account information 352 can include account numbers androuting information. In other embodiments, the account information 352can include credit card numbers, debit card numbers, or other types ofpayment information that may be used by the private payment system 108to obtain funds to push to a merchant 218 or to another user.

Friends information 354 can include information for people associatedwith the user 102. This friends information 354 may include one or moreof, but is not limited to, friend names, friend addresses, and/or friendaccount information. In other embodiments, other information is alsoincluded to identify the friends. Friends information 354 can be used tocreate IOUs in the tab subsystem 228. The tabs are explained inconjunction with FIGS. 3E and 3F and FIGS. 5A through 5C.

An embodiment of a tab 358 as used with the tab subsystem 228 is shownin FIGS. 3E and 3F. The tab 358 can include one or more items ofinformation, but is not limited to, a name 360, an ID 362, an IOU364/366, a you owe me (UOME) 368/370, and/or settlement information 372.The tab 358 can have more or fewer fields than those shown in FIG. 3E or3F, as represented by ellipses 374 and 382. The tab information createsIOUs between users 102. Thus, the IOU 364/366 can include informationabout a person either owing money to another person or the person thatis owed money.

The name field 360 includes the name of the user 120 that created thetab 358. In embodiments, the name 360 can be the person who owes money.The name 360 can be the same or similar to the name 338, as described inconjunction with FIG. 3D. As such, the name 360 can identify the useramongst all other users using the private payment system 108. The ID 362can include or be similar to the ID 340, as described in conjunctionwith FIG. 3D. The ID 362, therefore, also may uniquely identify theperson or user 102 that has created the tab 358 in the tab subsystem228.

Each tab 358 may include one or more IOUs 364/366 and/or one or moreUOMEs 368/370. An IOU 364/366 is a debt owed by the person identified bythe name 360 and ID 362. An IOU 364/366 recognizes that that person owesmoney to another user. An embodiment of an IOU 364/366 is shown inconjunction with FIG. 3F. Here, an IOU 364/366 can include one or moreof, but is not limited to, a tag 376, an amount 378, and/or a comment380. The IOU 364/366 can include more or fewer fields than that shown inFIG. 3F, as represented by ellipses 382. A tag 376 can be informationthat identifies the person or user that is owed money. The tag 376 caninclude any of the information in the user profile 336, as described inconjunction with FIG. 3D. In an embodiment, the tag 376 includes thefriends information 354 described in conjunction with FIG. 3D. Inalternative embodiments, the tag 376 can be the same or similar toinformation in FIGS. 3A and 3B. Regardless, the tag 376 identifies theperson that is owed money and may be used in fulfilling the tab or theIOU at a future time.

The amount 378 includes any monetary amount that may represent the debtfrom the user 102 to the person who is owed money. The amount 378 can berepresented in any currency as that currency may be converted by thecurrency subsystem 214. The comment 380 can be any comment to describethe IOU 364. The comment 380 can include why the IOU is owed or otherinformation that allows for the settlement of the IOU at some futuretime. The second IOU 366 can be a second debt from the user 102 owed tothe same person or to another person. Thus, the tab information 358 canrepresent transactions between two people or between the user 102 andone or more other people. The second IOU 366 can include the sameinformation as described in FIG. 3F.

A UOME 378 can be a credit owed to the person identified in the name 360and ID field 362. As such, the UOME 368 can include information that issent or received from another user about a debt owed by the other userto the person. A UOME 378 can include similar information to that foundin FIG. 3F but represent a credit that is owed to the person rather thana debt. The second UOME 370 can have similar information to the firstyou owe me 368 but may be a transaction or second credit owed to theperson either from the same person or from a different person. As such,the UOME 378 represents information about any transaction where the user102 is owed money.

Settlement information 372 can include any information about how tosettle the tabs. As such, the settlement information 372 can includeinformation within the user profile 336 or may include other informationthat is described in conjunction with FIG. 3A or 3B. Settlementinformation 372 may be used by the tab subsystem 228 to affect paymentor resolution of the tabs amongst two or more users.

An embodiment of a method 400 for pushing payment from a user 102 to amerchant 112 using tokens is shown in FIGS. 4A through 4D. FIG. 4B showsthe method 400 from the perspective of the merchant 112. FIG. 4C showsthe method 400 from the perspective of a private payment system 108, andFIG. 4D shows the method 400 from the perspective of a user 102.Generally, the method 400 begins with a start operation 401 andterminates with an end operation 424. While a general order for thesteps of the method 400 are shown in FIGS. 4A through 4D, the method 400can include more or fewer steps or arrange the order of the stepsdifferently than those shown in FIGS. 4A through 4D. The method 400 canbe executed as a set of computer-executable instructions executed by acomputer system and encoded or stored on a computer readable medium.Hereinafter, the method 400 shall be explained with reference to thesystems, components, modules, data structures, user interfaces, etc.described in conjunction with FIGS. 1-3F.

A merchant 112 provides a token 302, in step 402. The merchant 112 cancreate a token 302 as described in conjunction with FIGS. 3A through 3C.The token 302 may be provided in numerous ways. For example, the token302 may be provided in a catalog and be associated with a productmarketed within the catalog. In other embodiments, the merchant 112 mayprovide the token 302 in an advertisement within a periodical,publication, or an Internet page. The token 302 may also be associatedwith a service or good and may be provided to the user through othersources or methods. Regardless, the merchant sends or provides the tokento the user 102. Likewise, the user 102 receives the token from themerchant, in step 402, to begin a transaction to push payment to themerchant to receive the product or service associated with the token.

The user sends the token and, possibly, authentication information tothe private payment system 108, in step 404. Thus, the user communicatesthe information within the token, such as, the payee identity 304 andthe product or service 306 associated with the token 302 to the privatepayment system 108. In embodiments, the user enters the information intoa user interface on a user device and sends the token informationelectronically through a network 110A and gateway 106 to the privatepayment system 108. The token information may be received through thegateway 106 at a private processing switch 202. Recognizing the usersrequest to purchase a service or good using the token, the privateprocessing switch 202 can send the token to the user system 204.

Further, the private processing switch 202 can receive theauthentication information sent, by the user 102, and forward that userauthentication information to the user authentication subsystem 226. Instep 405, the user authentication subsystem 226 can determine if theuser is authenticated. Here, the user authentication subsystem 226 cancheck received user authentication information against authenticationinformation 348 stored within the user profile 336. If the receivedauthentication information, such as a user name and/or password, isauthenticated, step 405 proceeds YES to step 408. However, if the useris not authenticated, step 405 proceeds NO to step 406, where the useris denied the ability to conduct the transaction. As the denial of thetransaction is dependent on the user not being authenticated, step 406is optional. The user authentication subsystem 226 can send anindication, to private processing switch 202, that the user is notauthenticated. The private processing switch 202 then sends through, thegateway 106 and network 110, to the user 102 a denial of thetransaction. The user can receive the transaction denial, in step 406,to be informed that the customer will not be able to conduct thetransaction because the customer was not authenticated. It is possiblethat the user can resend authentication information, because theauthentication information may be entered or provided incorrectly, toretest the authentication or to reaffirm the authentication. Thus, themethod flows back to step 404 after the denial of transaction. In otherembodiments, the user may end a method 400 after the denial of thetransaction.

In step 408, the private processing switch 202 sends the tokeninformation to the merchant system 218. The merchant system 218 can thenprovide the product or service information and payee identity 304 to thetoken subsystem 202. The token subsystem 202 can create a request forproduct/service information that is sent to the merchant 112, in step408. The request sends the product or service information 306 from thetoken 302 to the payee or merchant 112 identified in the payee identity304. The request asks the merchant 112 for any information necessary topurchase the product or service. This information may include price orproduct or service identity. In embodiments, any information necessaryto fulfill a purchase order and or complete a payment transaction with amerchant's financial institution 236 is requested. The request isreceived by the merchant 112. The merchant 112 may process the requestand send the product or service information back to the private paymentsystem 108, in step 410. The token subsystem 220 may then provide theinformation for purchasing the service or good to the private processingswitch 202. This information can include any financial informationneeded for the user system 204 to acquire funds to push a payment to themerchant 112.

After receiving the product or service information from the privateprocessing switch 202, the user system 204 can determine if funds areavailable to push payment to the merchant's financial institution 236,in step 412. The user profile subsystem 216 can review user informationin the fulfillment information 346 and/or account information 352. Thisinformation indicates how the user desires to pay for the service orgood that is associated with the token. This information is then used bythe user system 204 to either check if funds are available with thecredit subsystem 210 or the debit subsystem 212. For example, if theusers decided to use a credit transaction, the credit subsystem 210determines if there is currently enough credit to pay for the product orservice. In other embodiments, if there is an account associated withthe user, the debit subsystem 212 determines if the account has enoughfunds to pay for the product or service associated with the token. Otherpayment vehicles or methods for transferring funds are possible andcontemplated. It is also possible for the user system 204 to approvepayment of a good or service and send the approval but have the actualfunding or settlement of the transaction occur at a later time.

In embodiments, the information received from the token subsystem 220may include a currency that is different than that used with the usersystem 204. In embodiments, the currency subsystem 214 can convert thecurrency received with the financial information into a currency used bythe credit subsystem 210 or debit subsystem 212. Upon determining if theaccount associated with the credit subsystem 210 or the debit subsystem212 has enough funds to pay for the product or service, the user system204 sends either an approval or a denial of the transaction to theprivate processing switch 202. If the user system 204 determines thefunds are not available, step 412 proceeds NO to step 406 where thetransaction is again denied. However, if funds are available, step 412proceeds YES to step 414.

The private payment system 108 sends payment to the merchant 112, instep 414. Here, the user system 204 sends or provides paymentinformation to the private processing switch 202. For example, the usersystem 204 can send the information about the funds to the privateprocessing switch 202, which forward the payment information to thepayment order subsystem 222. The payment order subsystem 222 then pushesa payment through the private payment fund subsystem 232 to themerchant's financial institution 236. The payment may be sent through anACH or EFT transaction. As such, the private payment system 108 pushesthe funds to the financial institution 236 without any accountinformation of the user being presented to the merchant 112 or themerchant's financial institution 236. Upon completion of the payment,the financial institution may provide back, to the private paymentsystem 108, an indication of whether the funds were properly transferredand payment has been received. This payment information is providedthrough the PPS fund subsystem 230 back to the payment order subsystem222. The payment order subsystem 222 then provides the paymentinformation to the private processing switch 202, which may forward thisinformation to the user system 204.

In alternative embodiments, all information about payment and orderingmay be sent in a single interaction, in step 415. Here, the order andpayment information may be updated by an application periodically in thePPS 108. Thus, the PPS 108 need not ask about the product/serviceinformation. Thus, the ordering and payment is streamlined without unduecommunications.

Upon receiving the confirmation that the payment is received, thepayment order subsystem 222 can generate a purchase order, in step 416.The purchase order can include any information necessary for themerchant 112 to complete the transaction or provide the service or goodto the user 102. The purchase order can include the payment confirmationand any of the other information associated within the token orassociated with the user 102 or token 302 that the merchant 112 mayneed. Upon completing the generation of the purchase order, the paymentorder subsystem 222 sends the purchase order to the merchant 112, instep 418. The merchant receives the purchase order, in step 418, andbegins the process of providing the service or good to the user. Thus,to complete the purchase order, the merchant 112 provides the user theproduct or service, in step 422. In embodiments, the payment ordersystem 222 includes any information from the fulfillment subsystem 206stored in the fulfillment information 346 on the user profile 336. Thisfulfillment information can include any information needed by themerchant 112 to send the product or service to the user 102. Forexample, the fulfillment information may include an electronic addressto send a software application for the user. Thus all transactiondetails are completed and the merchant 112 can provide the product orservice to the user knowing that payment has been completed. With thissystem, the user 102 and merchant 112 can complete a transaction withoutever exchanging financial information. The user can receive the productor service, in step 422. In embodiments, the user may also receive thepurchase information as sent from the private payment system 108 to thefinancial institution 236, in step 420. Thus, the user receives anyinformation about the transaction and the product or service.

An embodiment of a method 500 for creating tabs with the private paymentsystem 108 is shown in FIGS. 5A through 5C. A tab can be an IOU or youowe me associated between two users 102. Thus, the private paymentsystem 108 provides a method for creating credits or debits betweenusers without the users exchanging financial information. Inembodiments, FIG. 5B represents a perspective of the private paymentsystem 108 that organizes the IOUs. In contrast, FIG. 5C represents theperspective of at least one user 102 creating or receiving IOUinformation. Generally, the method 500 begins with a start operation 502and terminates with an end operation 528. While a general order for thesteps of the method 500 are shown in FIG. 5, the method 500 can includemore or fewer steps or the order of the steps may be arrangeddifferently than the method 500 shown in FIG. 5. The method 500 can be aset of computer-executable instructions executed by a computer system orprocessor and/or encoded or stored on a computer readable medium.Hereinafter, the method 500 shall be explained with reference to thesystems, components, modules, data structures, user interfaces, etc.described in conjunction with FIGS. 1-3F.

A user 102 can create an IOU by interfacing with the private paymentsystem 108 through a user device 102, which can include a computersystem, smart phone, mobile device, etc. Thus, the user may access a webservice or other computer-associated user interface to create an IOU tosend to the private processing switch 202. The user then sends theinformation about the IOU to the private processing switch 202, in step502. The private processing switch 202 receives the IOU command and IOUinformation, in step 502. The private processing switch 202 forwardsthis information to the tab subsystem 228. The tab system 228 creates atab 358 and stores that tab in the database 114, in step 508. The tabcan include one or more of the fields as described in conjunction withFIGS. 3E through 3F. This IOU information is stored in a tab databaseassociated with the user. Upon storing the tab, the tab subsystem 228can provide the information back to the private processing switch 202that can communicate the IOU to the first and second user, in step 510.Thus, the private processing switch 202 can send the IOU information ascreated by the first user, and send that information to the user throughthe gateway 106 network 110. The first user can receive the IOUinformation to determine if the IOU was correctly created. Further, theprivate processing switch 202 can send the IOU information to the seconduser. The IOU information sent to the second user can appear as a UOMEin the tabs database.

The private processing switch 202 may then receive one or more commandsfrom either the first or second user, in step 512. Thus, the first orsecond user may send a command to affect an action with the tab. Thecommands can conduct operations regarding the tab subsystem or createnew tabs. The private processing switch 108 determines if other commandsare received, in step 514. If further commands are received, step 514proceeds from YES to step 516. If no other commands are received, step514 proceeds NO to step 520. In step 516, the private processing switch202 receives the other commands. The private processing switch 202 maythen send the command to the tab subsystem 228, which executes thecommand, in step 518. Examples of the commands that may be received areprovided herein after.

An “I owe you” command (IO) can create a tab IOU 364. An IO command caninclude a “tag” 376, an “amount” 378, and a “comment” 380. The “tag”376, an “amount” 378, and a “comment” 380 may be as described inconjunction with FIG. 3F. An example of an IO command is: IO Dave 10.With this IO command, the sender is informing the PPS 108 and Dave thatthe sender owes Dave $10. The tab subsystem 228 opens a tab and notifiesDave and the sender that a tab has been opened and provides atransaction number.

A “You Owe Me” command (UO) can create an OME 368. When a UO command issent to PPS 108, the tab subsystem 228 can create a UOME tab havingsimilar fields to the IOU, e.g., “tag” 376, an “amount” 378, and a“comment” 380. The “tag” 376, an “amount” 378, and a “comment” 380 maybe as described in conjunction with FIG. 3F. An example of such a UOcommand is: UO Dave 10. With this UO command, the sender is informingthe tab subsystem 228 and Dave that Dave owes the sender $10. The tabsubsystem 228 opens a tab and notifies Dave and the sender that a tabhas been opened and provides a transaction number.

A “reject” command (RJCT) is used to reject a transaction (either an IOor UO). When the RJCT “tag” or RJCT “transaction” is sent, the “tag”identifies the individual whose transaction the sender wishes to rejectand “transaction number” identifies the specific transaction (forexample, see IO and UO above). In an example, a RJCT Dave tr3 (where tr3is the transaction number), the tab subsystem 228 identifies thetransaction, by first identifying the correct tab, which is indexed bythe sender's handle (which might be the mobile number or some othertag), and Dave's handle (once again, mobile number or some other tag).Within this tab, TR3 identifies the transaction in question and thus theamount in question. With this information, the tab subsystem 228 canremove or adjust the tab and then will notify both parties of thechange.

The tab command (AB) can be sent by a user to display currently open orunsettled tabs. For example, sending TAB to the PPS 108 will return thefollowing if open tabs: Dave owes you $10; Jim owes you $100; You oweSue $30, etc. If there are no open tabs, then the tab subsystem 228responds by saying that there are no open tabs. If the TAB command issent with a tag, then the tab subsystem 228 returns the transactionsassociated with the individual identified in the tag. For example, ifthe sender has an open tab with Dave, then sending the TAB Dave returns:TR1 You owe Dave—$10; TR2 Dave owes you—$20; TR3 Dave owes you—$40 **rejected; Net—Dave owes you $10. It is possible that some or all of theabove commands can occur automatically in an application that keeps arunning total of tabs and operates on the tabs to automatically reject,accept, or merge the tabs.

The settle command (STL) is the command for settling a tab. Sending STLtag, where tag is the designation of the individual with whom the senderwishes settle, instructs the tab subsystem 228 that the user wishes tohave the tab with the identified person settled. For example, sendingthe STL Dave command to the PPS 108, the tab subsystem 228 determinesthe balance of tabs with Dave, if any, and sends an invitation to theparty that owes the funds to initiate payment. In this case, Dave wouldget a message saying the he owes the sender of the settle command $10.If there is no tab open, then the tab subsystem 228 sends the sender amessage and invites the sender to use the tab command to identify opentabs. The tab subsystem 228 will remind Dave periodically if the paymentassociated with this tab is not paid. After some number of days, thesender has the option to “forgive” the tab, which will result in the tabsubsystem 228 not sending any additional reminders.

The PAY command would be used to pay another individual a certainamount. Sending the PAY command can be formatted with a “tag,” and“amount,” and a “PIN,” where tag and amount are as described with theIOU and the PIN is a password or personal identification number setup bythe sender ahead of time.

A block command (BLK) can be used to block all transactions from acertain mobile number or other user. The format of the command is BLK“tag,” where the tag may be the number of the mobile number to block. Anunblock command (UNBLK) will allow transactions from a previouslyblocked mobile number. The format of the command is UNBLK “tag,” wherethe tag may be the number of the mobile number to unblock.

A balance command (BAL) can be used to check the balance in an account.The format for the BAL command is BAL, “PIN,” where PIN is the passwordor personal Identification number discussed earlier.

A gift command is for sending a gift to another user. The format forthis command is gift, “tag,” “optional message,” “optional destination,”where tag is the recipient, the message (which is optional) contains agreeting (have a nice day, happy birthday etc.), and destinationdesignates where the funds are to go. For example, the tag or receivermay have setup a prepaid card or gift card from a merchant (e.g.Starbucks) and the sender may wish to buy the recipient (tag) a cup ofcoffee from Starbucks. Without a destination, the tab subsystem 228credits the receiver's account with the cash.

After all commands and IOUs are created, the tab subsystem 228 candisplay the tabs, in step 520. To display the tabs, the tab subsystem228 can create a user-centric view of the IOUs or UOMEs associated withthe user 102. Thus, any information regarding the IOUs or UOMEs may becreated and provided in a user interface to the user 102, such that, theuser can view IOUs or UOMEs by who the debt is owed or by who owes theUOMEs. The user may view this information or see the tabs, in step 520.Upon receiving the tabs, or at some point thereinafter, the user 102 maydecide to pay for the debts or receive money for the credits.

The user 102 can settle tabs, in step 522. In settling a tab, the user102 pays for any IOUs or requests payment for any UOMEs. The settlementmay be sent to the private processing switch 202, which is forwarded tothe tab subsystem 228. Depending on how the user decides to settle theIOUs and UOMEs, the tab subsystem 228 may calculate or resolve the debtsand credits internally. For example, any credits owed by one party maybe used to balance any debts owed to that party. Thus, the total amount,which is a balance of all credits and debts, may be established by thetab subsystem 228. Upon determining whether an amount is owed to anotherparty or another party owes the user 102, the tab subsystem 228 mayforward this information, through the private processing switch 202, tothe user system 102, in step 522. The user system may then requestpayment or make a payment through the credit subsystem or debitsubsystem to another user 102. Thus, payment may be sent, in step 524,by the user system 204 to another user's financial institution or to theuser's accounts within the private payment system 108. As such, the usercan push payment to another user without exchanging any financialinformation with that user. Upon completing payment for the tabs, theuser system may generate payment information, which may be sent throughthe private processing switch 202 to the user 102, in step 526. Uponreceiving payment information the user has completed the settlement ofthe tabs. It should be noted that the tabs and the commands associatedtherewith can be implemented through an application, SMS, IM, email,etc. Further, the operations executed on the tabs can be combined andpresented in convenient user interfaces to the user.

FIG. 6 illustrates a block diagram of a computing environment 600 thatmay function as system or environment for the embodiments describedherein. The system 600 includes one or more user computers 605, mobiledevices 610 (e.g., mobile phones, smart phones, tablet computers, etc.),and other user computing systems 615. The user computers 605, 610, and615 may be general purpose personal computers (including, merely by wayof example, personal computers and/or laptop computers running variousversions of Microsoft Corp.'s Windows™ and/or Apple Corp.'s Macintosh™operating systems) and/or workstation computers running any of a varietyof commercially-available UNIX™ or UNIX-like operating systems. Theseuser computers 605, 610, 615 may also have any of a variety ofapplications, including for example, database client and/or serverapplications, and web browser applications. Alternatively, the usercomputers 605, 610, and 615 may be any other electronic device, such asa thin-client computer, Internet-enabled mobile telephone, and/orpersonal digital assistant, capable of communicating via a network(e.g., the network 620 described below) and/or displaying and navigatingweb pages or other types of electronic documents. Although the exemplarysystem 600 is shown with three user computers, any number of usercomputers may be supported.

System 600 further includes a network 620. The network 620 can be anytype of network familiar to those skilled in the art that can supportdata communications using any of a variety of commercially-availableprotocols, including, without limitation, TCP/IP, SNA, IPX, AppleTalk,and the like. Merely by way of example, the network 620 maybe a localarea network (“LAN”), such as an Ethernet network, a Token-Ring networkand/or the like; a wide-area network; a virtual network, including,without limitation, a virtual private network (“VPN”); the Internet; anintranet; an extranet; a public switched telephone network (“PSTN”); aninfra-red network; a wireless network (e.g., a network operating underany of the IEEE 802.11 suite of protocols, networks operating incompliance with the Bluetooth™ protocol known in the art, and/or anyother wireless protocol); and/or any combination of these or othernetworks.

The system 600 may also include one or more server computers 625, 630.One server may be a web server 625, which may be used to processrequests for web pages or other electronic documents from user computers605, 610, and 615. The web server can be running an operating systemincluding any of those discussed above, as well as anycommercially-available server operating systems. The web server 625 canalso run a variety of server applications, including HTTP servers, FTPservers, CGI servers, database servers, Java servers, and the like. Insome instances, the web server 625 may publish operations availableoperations as one or more web services.

The system 600 may also include one or more file and or/applicationservers 630, which can, in addition to an operating system, include oneor more applications accessible by a client running on one or more ofthe user computers 605, 610, 615. The server(s) 630 may be one or moregeneral purpose computers capable of executing programs or scripts inresponse to the user computers 605, 610 and 615. As one example, theserver may execute one or more web applications. The web application maybe implemented as one or more scripts or programs written in anyprogramming language, such as Java™, C, C#™ or C++, and/or any scriptinglanguage, such as Perl, Python, MySQL, or TCL, as well as combinationsof any programming/scripting languages. The application server(s) 630may also include database servers, including without limitation thosecommercially available from Oracle, Microsoft, Sybase™, IBM™ and thelike, which can process requests from database clients running on a usercomputer 605.

The web pages created by the web application server 630 may be forwardedto a user computer 605 via a web server 625. Similarly, the web server625 may be able to receive web page requests, web services invocations,and/or input data from a user computer 605 and can forward the web pagerequests and/or input data to the web application server 630. In furtherembodiments, the server 630 may function as a file server. Although forease of description, FIG. 5 illustrates a separate web server 625 andfile/application server 630, those skilled in the art will recognizethat the functions described with respect to servers 625, 630 may beperformed by a single server and/or a plurality of specialized servers,depending on implementation-specific needs and parameters. The computersystems 605, 610, and 615, file server 625 and/or application server 630may function as servers or other systems described herein.

The system 600 may also include a database 635. The database 635 mayreside in a variety of locations. By way of example, database 635 mayreside on a storage medium local to (and/or resident in) one or more ofthe computers 605, 610, 615, 625, 630. Alternatively, it may be remotefrom any or all of the computers 605, 610, 615, 625, 630, and incommunication (e.g., via the network 620) with one or more of these. Ina particular set of embodiments, the database 635 may reside in astorage-area network (“SAN”) familiar to those skilled in the art.Similarly, any necessary files for performing the functions attributedto the computers 605, 610, 615, 625, 630 may be stored locally on therespective computer and/or remotely, as appropriate. In one set ofembodiments, the database 635 may be a relational database, such asOracle 10i™, that is adapted to store, update, and retrieve data inresponse to SQL-formatted commands. Database 635 may be the same orsimilar to the database used herein.

FIG. 7 illustrates one embodiment of a computer system 700 upon whichservers or other systems described herein may be deployed or executed.The computer system 700 is shown comprising hardware elements that maybe electrically coupled via a bus 755. The hardware elements may includeone or more central processing units (CPUs) 705; one or more inputdevices 710 (e.g., a mouse, a keyboard, etc.); and one or more outputdevices 715 (e.g., a display device, a printer, etc.). The computersystem 700 may also include one or more storage devices 720. By way ofexample, storage device(s) 720 may be disk drives, optical storagedevices, solid-state storage device, such as a random access memory(“RAM”) and/or a read-only memory (“ROM”), which can be programmable,flash-updateable and/or the like.

The computer system 700 may additionally include a computer-readablestorage media reader 725; a communications system 730 (e.g., a modem, anetwork card (wireless or wired), an infra-red communication device,etc.); and working memory 740, which may include RAM and ROM devices asdescribed above. In some embodiments, the computer system 700 may alsoinclude a processing acceleration unit 735, which can include a DSP, aspecial-purpose processor and/or the like.

The computer-readable storage media reader 725 can further be connectedto a computer-readable storage medium, together (and, optionally, incombination with storage device(s) 720) comprehensively representingremote, local, fixed, and/or removable storage devices plus storagemedia for temporarily and/or more permanently containingcomputer-readable information. The communications system 730 may permitdata to be exchanged with the network 720 and/or any other computerdescribed above with respect to the system 700. Moreover, as disclosedherein, the term “storage medium” may represent one or more devices forstoring data, including read only memory (ROM), random access memory(RAM), magnetic RAM, core memory, magnetic disk storage mediums, opticalstorage mediums, flash memory devices and/or other machine readablemediums for storing information.

The computer system 700 may also comprise software elements, shown asbeing currently located within a working memory 740, including anoperating system 745 and/or other code 750, such as program codeimplementing the servers or devices described herein. It should beappreciated that alternate embodiments of a computer system 700 may havenumerous variations from that described above. For example, customizedhardware might also be used and/or particular elements might beimplemented in hardware, software (including portable software, such asapplets), or both. Further, connection to other computing devices suchas network input/output devices may be employed.

There are several examples where the PPS 108 can be used fortransactions. In an example, a concert promoter or even the band ororchestra can sign-up with PPS 108 to make their performance orrecordings available to members in the audience who are also users ofPPS 108. The producer of the show or even the band or orchestra isassigned a merchant code when they sign up with PPS 108. They can alsoassign SKU numbers to their products (live music as well aspre-recorded). The combination of the merchant code and SKU number willnow constitute the token. An audience member, during the show, can usetheir mobile device to place an order for music (either the live versionor pre-recorded) by using the appropriate token for the particular pieceof music. The PPS 108 will process the transaction and deliver the musicto their email address or even mobile device.

In another example, a charitable or non-profit organization can sign-upfor a merchant/organization code and an event code that can both beadvertised to the public. Users of PPS 108 can then make charitabledonations to these organizations without disclosing payment information.For example, a pledge drive, by a public TV or radio station, can beadvertised by announcing the PPS 108 token in addition to traditionalpayment methods. A PPS 108 user can then “push” a payment to thatorganization without disclosing that user's payment information. Acharitable organization wishing to raise funds to help the needy after acatastrophe can advertise their organization code along with an eventcode that is tied to that particular catastrophe thereby allowing usersof PPS 108 to donate impulsively and without compromising or disclosingtheir payment information. Examples of such organizations might includeNational Public Radio, the Redcross, various churches, temples,political organizations, etc.

In another example, a political campaign could sign-up for a token withPPS 108 that could be advertised at a rally (political, religious etc.).Audience members, who are members of PPS 108, can donate funds to thattoken without ever disclosing their payment information.

In another example, a radio or TV channel (station) could sign-up for amerchant token and setup a SKU number for their products. For example, ashopping network can sign-up, with the PPS 108, for a merchant code andutilize their existing product numbers to create the token. A music TVstation can also sign-up for a merchant code and assign a SKU number tothe music videos that they play. A radio station can sign-up for amerchant code and setup a SKU number for each piece of music that theyplay. A PPS 108 user who listens to that radio station or views thatchannel can use PPS 108 to purchase that product, music or video just byusing the assigned tokens but without disclosing their paymentinformation.

In another example, an internet merchant can sign-up for a PPS 108merchant code. When a PPS 108 user is ready to pay for purchases, he orshe can select PPS 108 as one of the payment options. The merchant'ssystem notifies PPS 108 of the purchase amount and other information,including SKU numbers for products in the user's shopping cart, and PPS108 generates a one-time only invoice number and sends it to themerchant. The user then uses the merchant number and this one-timeinvoice number as the tokens and makes the payment via PPS 108 withoutdisclosing the user's payment information to the merchant therebyreducing if not eliminating the threat of identity theft.

A brick-and-mortar merchant would also PPS 108 the very same way. Amerchant would sign-up for a PPS 108 merchant code. At check-out time,the final settlement amount and invoice are electronically transmittedto PPS 108 which in turn generates a token that is sent to the POSterminal. The cashier provides the token to the user who thenfacilitates a payment by sending the token to PPS 108. Upon reception ofthe token, PPS 108 authenticates the users and issues either a paymentor credit to the merchant and notifies that POS terminal. Once again,the user's information is not disclosed to the cashier.

In another example, a visitor to a store could identify an item ofinterest and make an electronic purchase as follows (i.e. not use thestore's point of sale or cashier): The customer sends product SKU orname or some other product description along with the merchant code toPPS 108 and PPS 108 can facilitate not only the purchase but alsodelivery of that item to the buyer's home or to someone else (in thenetwork as described below). Such a capability allows the customer theability to avoid waiting in line at the cashier and perhaps even dealingwith taking possession of large and cumbersome items. Of course, thepurchaser may also send the product description to a competing retaileror even a comparative shopping site and make a purchase from thecompeting retailer.

In another example, a publisher can sign-up with PPS 108 to facilitaterapid and spontaneous purchase of the publisher's products. Such apurchase maybe facilitated during promotional events that are hosted ontelevision (shows such as the Oprah Winfrey show), newspaperadvertisements as well as radio events, internet events and even mobilephone events.

In another example, a network marketing company can sign-up with PPS 108to allow their customers to rapidly and spontaneously make purchasesfrom catalogs as well as purchase events held at the homes of sellers ofsuch products.

In one example, a group of individuals might go for a night out, apicnic, a weekend ski trip, a trip to the beach or some other activity.As is often the case, different individuals pay for different productsor services (e.g. one individual pays for the cabin, another buys allthe ski lift tickets, another rents the cars or van and another mightpay for show tickets). Often, these expenses are tallied at the end ofthe trip and settled using cash or check. PPS 108 provides a capabilityfor individuals to open and maintain tabs between individuals, populatethe tabs using “I owe you” and “you owe me” commands, settle the tab(calculate who owe how much and to whom) and then push payments to theappropriate individuals.

In another example, a group of individuals might like to go together toa sporting event, a concert, a movie, a play etc. One individual mightpurchase the tickets for the whole group and collect payment from theother individuals in the group. In this case, PPS 108 can be used by thebuyer to open a tab with each individual in the group where the buyersends “you owe me” commands to the others through PPS 108 or by theothers sending “I owe you” commands or a combination of both. Theindividuals can then use PPS 108 to settle the “tab” at an appropriatetime and pay the owed amounts.

Similarly, in another example, a group of parents might wish to purchasea thank-you gift for a teacher. Once again, one individual can purchasethe gift on behalf of all the parents and then use PPS 108 to settlepayment.

In the foregoing description, for the purposes of illustration, methodswere described in a particular order. It should be appreciated that inalternate embodiments, the methods may be performed in a different orderthan that described. It should also be appreciated that the methodsdescribed above may be performed by hardware components or may beembodied in sequences of machine-executable instructions, which may beused to cause a machine, such as a general-purpose or special-purposeprocessor or logic circuits programmed with the instructions to performthe methods. These machine-executable instructions may be stored on oneor more machine readable mediums, such as CD-ROMs or other types ofoptical disks, floppy diskettes, ROMs, RAMs, EPROMs, EEPROMs, magneticor optical cards, flash memory, or other types of machine-readablemediums suitable for storing electronic instructions. Alternatively, themethods may be performed by a combination of hardware and software.

Specific details were given in the description to provide a thoroughunderstanding of the embodiments. However, it will be understood by oneof ordinary skill in the art that the embodiments may be practicedwithout these specific details. For example, circuits may be shown inblock diagrams in order not to obscure the embodiments in unnecessarydetail. In other instances, well-known circuits, processes, algorithms,structures, and techniques may be shown without unnecessary detail inorder to avoid obscuring the embodiments.

Also, it is noted that the embodiments were described as a process whichis depicted as a flowchart, a flow diagram, a data flow diagram, astructure diagram, or a block diagram. Although a flowchart may describethe operations as a sequential process, many of the operations can beperformed in parallel or concurrently. In addition, the order of theoperations may be re-arranged. A process is terminated when itsoperations are completed, but could have additional steps not includedin the figure. A process may correspond to a method, a function, aprocedure, a subroutine, a subprogram, etc. When a process correspondsto a function, its termination corresponds to a return of the functionto the calling function or the main function.

Furthermore, embodiments may be implemented by hardware, software,firmware, middleware, microcode, hardware description languages, or anycombination thereof. When implemented in software, firmware, middlewareor microcode, the program code or code segments to perform the necessarytasks may be stored in a machine readable medium such as storage medium.A processor(s) may perform the necessary tasks. A code segment mayrepresent a procedure, a function, a subprogram, a program, a routine, asubroutine, a module, a software package, a class, or any combination ofinstructions, data structures, or program statements. A code segment maybe coupled to another code segment or a hardware circuit by passingand/or receiving information, data, arguments, parameters, or memorycontents. Information, arguments, parameters, data, etc. may be passed,forwarded, or transmitted via any suitable means including memorysharing, message passing, token passing, network transmission, etc.

While illustrative embodiments of the embodiments have been described indetail herein, it is to be understood that the inventive concepts may beotherwise variously embodied and employed, and that the appended claimsare intended to be construed to include such variations, except aslimited by the prior art.

What is claimed is:
 1. A method, comprising: providing a private paymentcomputer system associated with a purchaser, the private paymentcomputer system comprising one or more file servers and/or applicationservers, a gateway, and a database, in communication with one another,the private payment computer system further comprising hardware elementselectrically coupled via a bus, the hardware elements including one ormore central processing units to execute a program and/or script for theone or more file servers and/or application servers and a non-transitorycomputer readable storage medium storing the database and instructionsfor the program and/or script; creating, by the private payment computersystem, at least part of a token for a merchant offering a productand/or service to be purchased by the purchaser, the token including (a)a payee identifier that (i) identifies financial information of themerchant, the merchant financial information comprising one or more of auniversal payment identification code associated with the merchant, afinancial institution account number of the merchant, and a routingnumber of a financial institution of the merchant and (ii) includes oneor more of a unique merchant name, a globally unique identifier of themerchant, an alpha numeric number associated with the merchant, aspecialized name or abbreviation of the merchant, and a phone number ofthe merchant, and (b) a product and/or service identifier thatidentifies the product and/or service associated with the merchant;during a transaction by the purchaser to purchase the product and/orservice, receiving, at the gateway of the private payment computersystem directly from a computing system of the purchaser and through acommunication network, the token and authentication information of thepurchaser; authenticating, by the one or more file servers and/orapplication servers of the private payment computer system, thepurchaser using the received authentication information; when thepurchaser is authenticated successfully, retrieving, by the one or morefile servers and/or application servers of the private payment computersystem, merchant information from the database via the one or moredatabase servers, the retrieved merchant information associated with themerchant; sending, by the one or more file servers and/or applicationservers of the private payment computer system and using the retrievedmerchant information, a request for further information to a merchantsystem of the merchant about the product and/or service associated withthe token; receiving, by the one or more file servers and/or applicationservers of the private payment computer system, the requested furtherinformation from the merchant system; after verification that an accountof the purchaser has funds available to pay for the product and/orservice and upon completion of the payment transfer from an account ofthe purchaser to an account of the merchant, performing at least one ofthe following: sending, by the one or more file servers and/orapplication servers of the private payment computer system, to themerchant system, an electronic purchase order for the product and/orservice associated with the token and identified by the product and/orservice identifier; and sending, by the one or more file servers and/orapplication servers of the private payment computer system, electronicpayment confirmation that funds have been transferred from an account ofthe purchaser to an account identified at least in part by the payeeidentifier.
 2. The method as defined in claim 1, wherein an electronicpurchase order is sent to the merchant system, wherein the purchaseorder includes fulfillment information describing how to provide theproduct and/or service associated with the token, and wherein theproduct and/or service is provided to the purchaser in conformance withthe fulfillment information.
 3. The method as defined in claim 2,wherein a payment is pushed to the merchant financial institution. 4.The method as defined in claim 3, wherein the electronic paymentconfirmation is generated from the payment being pushed to the merchantfinancial institution.
 5. The method as defined in claim 4, wherein themerchant does not receive account information from the purchaser whenthe payment is pushed to the financial institution.
 6. The method ofclaim 1, further comprising: sending, by the one or more file serversand/or application servers of the private payment computer system, tothe merchant system the electronic purchase order for the product and/orservice associated with the token and identified by the product and/orservice identifier.
 7. The method of claim 1, wherein the one or morefile servers and/or application servers of the private payment computersystem comprise a plurality of a web server, a database server, webapplication server, and file server, wherein the private paymentcomputer system comprises one or more user input devices comprising oneor more of a mouse and keyboard and one or more user output devicescomprising of a display device and printer, wherein the one or morecentral processing units comprise a processing acceleration unit,wherein the private payment computer system comprises one or more of amodem, network card, and infra-red communication device, and wherein thecomputer readable storage medium comprises one or more of a read onlymemory and a random access memory and one or more of a magnetic storagemedium, optical storage medium, and solid-state storage device.
 8. Themethod of claim 1, wherein the purchaser authentication informationcomprises a password, username, or personal identification number of thepurchaser and an electronic address of the purchaser's computing system.9. The method of claim 8, wherein the token comprises one or more of astock keeping unit number of the product and/or service of the merchant,a unique name of the product and/or service, a merchant catalog number,and price information of the product and/or service.
 10. The method ofclaim 1, wherein the private payment computer system performs thereceiving, authenticating, retrieving, and performing without thepurchaser providing purchaser financial account information to themerchant or merchant system.
 11. The method of claim 1, furthercomprising: retrieving merchant information associated with the payeeidentifier; and sending payment to a financial institution associatedwith the merchant and at least partly identified by the payee identifierin the token.
 12. The method of claim 1, wherein the token is receivedby the gateway of the private payment computer system from thepurchaser's computing system through the Internet and wherein, duringtransmission of the token from the purchaser's computing system to theprivate payment computer system, the token does not pass through themerchant system.
 13. The method of claim 1, wherein the purchaser'scomputing system obtains the token by one or more of manual input via auser interface by the purchaser and via a web browser from an Internetpage provided by a web server of the merchant system.
 14. The method ofclaim 1, wherein the private payment computer system generates theentire token and provides the token to the merchant system during thepurchase transaction between the purchaser and merchant and wherein themerchant system provides the token to the purchaser's computing systemto forward to the private payment computer system.
 15. A method,comprising: providing a private payment computer system associated witha purchaser, the private payment computer system comprising one or morefile servers and/or application servers, a gateway, and a database, incommunication with one another, the private payment computer systemfurther comprising hardware elements electrically coupled via a busand/or network, the hardware elements including one or more centralprocessing units to execute a program and/or script for the one or morefile servers and/or application servers and a non-transitory computerreadable storage medium storing the database and instructions for theprogram and/or script; creating, by the private payment computer system,at least part of a token for a merchant offering a product and/orservice to be purchased by the purchaser, the token including (a) apayee identifier that (i) identifies financial information of themerchant, the merchant financial information comprising one or more of auniversal payment identification code associated with the merchant, afinancial institution account number of the merchant, and a routingnumber of a financial institution of the merchant and (ii) includes oneor more of a unique merchant name, a globally unique identifier of themerchant, an alpha numeric number associated with the merchant, aspecialized name or abbreviation of the merchant, and a phone number ofthe merchant, and (b) a product and/or service identifier thatidentifies the product and/or service associated with the merchant;during a transaction by the purchaser to purchase the product and/orservice, receiving, at the gateway of the private payment computersystem directly from a computing system of the purchaser and through acommunication network, the token and authentication information of thepurchaser; authenticating, by the one or more file servers and/orapplication servers of the private payment computer system, thepurchaser using the received authentication information; when thepurchaser is authenticated successfully, retrieving, by the one or morefile servers and/or application servers of the private payment computersystem, merchant information from the database via the one or moredatabase servers, the retrieved merchant information associated with themerchant; after verification that an account of the purchaser has fundsavailable to pay for the product and/or service and upon completion ofthe payment transfer from an account of the purchaser to an account ofthe merchant, performing at least one of the following: sending, by theone or more file servers and/or application servers of the privatepayment computer system, to the merchant system, an electronic purchaseorder for the product and/or service associated with the token andidentified by the product and/or service identifier; and sending, by theone or more file servers and/or application servers of the privatepayment computer system, electronic payment confirmation that funds havebeen transferred from an account of the purchaser to an accountidentified at least in part by the payee identifier.
 16. The method ofclaim 15, further comprising: sending, by the one or more file serversand/or application servers of the private payment computer system, theelectronic payment confirmation that funds have been transferred from anaccount of the purchaser to an account identified at least in part bythe payee identifier.
 17. The method of claim 15, wherein the one ormore file servers and/or application servers of the private paymentcomputer system comprise a plurality of a web server, a database server,web application server, and file server, wherein the private paymentcomputer system comprises one or more user input devices comprising oneor more of a mouse and keyboard and one or more user output devicescomprising of a display device and printer, wherein the one or morecentral processing units comprise a processing acceleration unit,wherein the private payment computer system comprises one or more of amodem, network card, and infra-red communication device, and wherein thecomputer readable storage medium comprises one or more of a read onlymemory and a random access memory and one or more of a magnetic storagemedium, optical storage medium, and solid-state storage device.
 18. Themethod of claim 15, wherein the purchaser authentication informationcomprises a password, username, or personal identification number of thepurchaser and an electronic address of the purchaser's computing system.19. The method of claim 18, wherein the token comprises one or more of astock keeping unit number of the product and/or service of the merchant,a unique name of the product and/or service, a merchant catalog number,and price information of the product and/or service.
 20. The method ofclaim 15, wherein the private payment computer system performs thereceiving, authenticating, retrieving, and performing without thepurchaser providing purchaser financial account information to themerchant or merchant system.
 21. The method of claim 15, furthercomprising: retrieving merchant information associated with the payeeidentifier; and sending payment to a financial institution associatedwith the merchant and at least partly identified by the payee identifierin the token.
 22. The method of claim 15, wherein the token is receivedby the gateway from the purchaser's computing system through theInternet and wherein, during transmission of the token from thepurchaser's computing system to the private payment computer system, thetoken does not pass through the merchant system.
 23. The method of claim15, wherein the purchaser's computing system obtains the token by one ormore of manual input via a user interface by the purchaser and via a webbrowser from an Internet page provided by a web server of the merchantsystem.
 24. The method of claim 15, wherein the private payment computersystem generates the entire token and provides the token to the merchantsystem during the purchase transaction between the purchaser andmerchant and wherein the merchant system provides the token to thepurchaser's computing system to forward to the private payment computersystem.
 25. A private payment computer system, comprising: one or morecentral processing units to execute a program and/or script for one ormore file servers and/or application servers; a non-transitory computerreadable storage medium storing the instructions; a gateway to sendcommunications to and receive communications from a communicationsnetwork; and a bus electrically coupling the one or more centralprocessing units, and the non-transitory computer readable storagemedium, the non-transitory computer readable storage medium comprisingthe program and/or script that, when executed by the one or more centralprocessing units, cause the one or more central processing units to:create at least part of a token for a merchant offering a product and/orservice to be purchased by a purchaser, the token including (a) a payeeidentifier that (i) identifies financial information of the merchant,the merchant financial information comprising one or more of a universalpayment identification code associated with the merchant, a financialinstitution account number of the merchant, and a routing number of afinancial institution of the merchant and (ii) includes one or more of aunique merchant name, a globally unique identifier of the merchant, analpha numeric number associated with the merchant, a specialized name orabbreviation of the merchant, and a phone number of the merchant, and(b) a product and/or service identifier that identifies the productand/or service associated with the merchant; during a transaction by thepurchaser to purchase the product and/or service, receive, directly froma computing system of the purchaser and through the communicationnetwork, the token and authentication information of the purchaser;authenticate the purchaser using the received authenticationinformation; when the purchaser is authenticated successfully, retrievemerchant information from the database via the one or more databaseservers, the retrieved merchant information associated with themerchant; and after verification that an account of the purchaser hasfunds available to pay for the product and/or service and uponcompletion of the payment transfer from an account of the purchaser toan account of the merchant, perform at least one of the following: sendto the merchant system, an electronic purchase order for the productand/or service associated with the token and identified by the productand/or service identifier; and send electronic payment confirmation thatfunds have been transferred from an account of the purchaser to anaccount identified at least in part by the payee identifier.
 26. Theprivate payment computer system of claim 25, wherein the one or morecentral processing units: send, using the retrieved merchantinformation, a request for further information to a merchant system ofthe merchant about the product and/or service associated with the token;and receive the requested further information from the merchant system.27. The private payment computer system of claim 25, wherein the one ormore file servers and/or application servers comprise a plurality of aweb server, a database server, web application server, and file server,wherein the private payment computer system comprises one or more userinput devices comprising one or more of a mouse and keyboard and one ormore user output devices comprising of a display device and printer,wherein the one or more central processing units comprise a processingacceleration unit, wherein the private payment computer system comprisesone or more of a modem, network card, and infra-red communicationdevice, and wherein the non-transitory computer readable storage mediumcomprises one or more of a read only memory and a random access memoryand one or more of a magnetic storage medium, optical storage medium,and solid-state storage device.
 28. The private payment computer systemof claim 25, wherein the purchaser authentication information comprisesa password, username, or personal identification number of the purchaserand an electronic address of the purchaser's computing system.
 29. Theprivate payment computer system of claim 28, wherein the token comprisesone or more of a stock keeping unit number of the product and/or serviceof the merchant, a unique name of the product and/or service, a merchantcatalog number, and price information of the product and/or service. 30.The private payment computer system of claim 25, wherein the receiving,authenticating, retrieving, and performing operations are performedwithout the purchaser providing purchaser financial account informationto the merchant or merchant system.
 31. The private payment computersystem of claim 25, wherein the one or more central processing units:retrieve merchant information associated with the payee identifier; andsend payment to a financial institution associated with the merchant andat least partly identified by the payee identifier in the token.
 32. Theprivate payment computer system of claim 25, wherein the token isreceived by the gateway from the purchaser's computing system throughthe Internet and wherein, during transmission of the token from thepurchaser's computing system to the private payment computer system, thetoken does not pass through the merchant system.
 33. The private paymentcomputer system of claim 25, wherein the purchaser's computing systemobtains the token by one or more of manual input via a user interface bythe purchaser and via a web browser from an Internet page provided by aweb server of the merchant system.
 34. The private payment computersystem of claim 25, wherein the private payment computer systemgenerates the entire token and provides the token to the merchant systemduring the purchase transaction between the purchaser and merchant andwherein the merchant system provides the token to the purchaser'scomputing system to forward to the private payment computer system. 35.A non-transitory computer readable storage medium comprising: one ormore instructions that, when executed by one or more central processingunits of a private payment computer system associated with a purchaser,create at least part of a token for a merchant offering a product and/orservice to be purchased by the purchaser, the private payment computersystem comprising one or more file servers and/or application servers, agateway, and a database, in communication with one another and furthercomprising hardware elements electrically coupled via a bus and/ornetwork, the hardware elements including the one or more centralprocessing units to execute a program and/or script for the one or morefile servers and/or application servers, and the non-transitory computerreadable storage medium storing the instructions and database and thetoken including (a) a payee identifier that (i) identifies financialinformation of the merchant, the merchant financial informationcomprising one or more of a universal payment identification codeassociated with the merchant, a financial institution account number ofthe merchant, and a routing number of a financial institution of themerchant and (ii) includes one or more of a unique merchant name, aglobally unique identifier of the merchant, an alpha numeric numberassociated with the merchant, a specialized name or abbreviation of themerchant, and a phone number of the merchant, and (b) a product and/orservice identifier that identifies the product and/or service associatedwith the merchant; one or more instructions that, when executed by theone or more central processing units of the private payment computersystem, receive, during a transaction by the purchaser to purchase theproduct and/or service, directly from a computing system of thepurchaser, and through the communication network, the token andauthentication information of the purchaser; one or more instructionsthat, when executed by the one or more central processing units of theprivate payment computer system, authenticate the purchaser using thereceived authentication information; one or more instructions that, whenexecuted by the one or more central processing units of the privatepayment computer system, retrieve, when the purchaser is authenticatedsuccessfully, merchant information from the database via the one or moredatabase servers, the retrieved merchant information associated with themerchant; and one or more instructions that, when executed by the one ormore central processing units of the private payment computer system,perform, after verification that an account of the purchaser has fundsavailable to pay for the product and/or service and upon completion ofthe payment transfer from an account of the purchaser to an account ofthe merchant, at least one of the following functions: send to themerchant system, an electronic purchase order for the product and/orservice associated with the token and identified by the product and/orservice identifier; and send electronic payment confirmation that fundshave been transferred from an account of the purchaser to an accountidentified at least in part by the payee identifier.
 36. Thenon-transitory computer readable storage medium of claim 35, furthercomprising: one or more instructions that, when executed by the one ormore central processing units of the private payment computer system,send, using the retrieved merchant information, a request for furtherinformation to a merchant system of the merchant about the productand/or service associated with the token; and one or more instructionsthat, when executed by the one or more central processing units of theprivate payment computer system, receive the requested furtherinformation from the merchant system.
 37. The non-transitory computerreadable storage medium of claim 35, wherein the one or more fileservers and/or application servers comprise a plurality of a web server,a database server, web application server, and file server, wherein theprivate payment computer system comprises one or more user input devicescomprising one or more of a mouse and keyboard and one or more useroutput devices comprising of a display device and printer, wherein theone or more central processing units comprise a processing accelerationunit, wherein the private payment computer system comprises one or moreof a modem, network card, and infra-red communication device, andwherein the non-transitory computer readable storage medium comprisesone or more of a read only memory and a random access memory and one ormore of a magnetic storage medium, optical storage medium, andsolid-state storage device.
 38. The non-transitory computer readablestorage medium of claim 35, wherein the purchaser authenticationinformation comprises a password, username, or personal identificationnumber of the purchaser and an electronic address of the purchaser'scomputing system.
 39. The non-transitory computer readable storagemedium of claim 38, wherein the token comprises one or more of a stockkeeping unit number of the product and/or service of the merchant, aunique name of the product and/or service, a merchant catalog number,and price information of the product and/or service.
 40. Thenon-transitory computer readable storage medium of claim 35, wherein thereceiving, authenticating, retrieving, and performing functions areperformed without the purchaser providing purchaser financial accountinformation to the merchant or merchant system.
 41. The non-transitorycomputer readable storage medium of claim 35, further comprising: one ormore instructions that, when executed by the one or more centralprocessing units of the private payment computer system, retrievemerchant information associated with the payee identifier; and one ormore instructions that, when executed by the one or more centralprocessing units of the private payment computer system, send payment toa financial institution associated with the merchant and at least partlyidentified by the payee identifier in the token.
 42. The non-transitorycomputer readable storage medium of claim 35, wherein the token isreceived by the gateway from the purchaser's computing system throughthe Internet and wherein, during transmission of the token from thepurchaser's computing system to the private payment computer system, thetoken does not pass through the merchant system.
 43. The non-transitorycomputer readable storage medium of claim 35, wherein the purchaser'scomputing system obtains the token by one or more of manual input via auser interface by the purchaser and via a web browser from an Internetpage provided by a web server of the merchant system.
 44. Thenon-transitory computer readable storage medium of claim 35, wherein theprivate payment computer system generates the entire token and providesthe token to the merchant system during the purchase transaction betweenthe purchaser and merchant and wherein the merchant system provides thetoken to the purchaser's computing system to forward to the privatepayment computer system.